"כמה גרוע זה כבר יכול להיות" - מחקר חולשות על נתב ביתי

Transcription

1 כבר יכול להיות" - מחקר חולשות על נתב ביתי מאת 0x3d b הקדמה במאמר זה אחשוף מחקר עצמאי אשר ביצעתי ובמסגרתו מצאתי מספר חולשות הרצת קוד על ראוטר.Netgear DGN2200 נתבים אלו נפוצים במיוחד בארץ עקב כך שחברת בזק מחלקת / חילקה אותן כחלק מחבילות השירות שלה. אני מציין בכוונה כאן את חברת בזק מכיוון שחקרתי firmware שלהם ולא firmware של,Netgear אף על פי שככל הנראה גם נתבים "טבעיים" של Netgear גם פגיעים בגרסאות מסויימות. עד כמה שאני מבין, החולשה תוקנה כבר על ידי "בזק", אך חשוב לציין שישנם המון נתבים לא מעודכנים ולפיכך צפוי שמספר גדול של ראוטרים עדיין פגיע. אציין כי חברת בזק שיתפה פעולה באופן מלא )בניגוד לחברת Netgear שניסתה בעיקר לזרוק אחריות(, ומודעים לשחרור מאמר זה. השתלשלות האירועים גילוי 3 חולשות ראשוניות המצויינות במאמר זה )חולשות #1, #2 ו- #4 ( פנייה אל חברת Netgear ומסירת הפרטים הטכניים, כולל.PoC תגובה של חברת Netgear שלצערי גלגלו אחריות אל "בזק" מציאת חולשה נוספת )חולשה #3( ודיווח נוסף עליה פנייה אל חברת "בזק" תגובה ראשונית של "בזק" ומסירת פרטים טכניים תיקון ראשוני של חולשה #2 של בזק שחרור קוד ה- PoC לאינטרנט תוך מעקב צמוד של בזק.

2 תחילת המחקר מטרת העל היא למצוא דרך להריץ קוד על ראוטר מתוך רגל ה- WAN. מטרה זו תתבצע במספר חלקים, כאשר החולשות "מועמסות" אחת על גבי השנייה. המחקר שלנו יתחיל בשאלה: "מה ניתן לעשות מתוך ה- LAN?", ולאחר מכן יתפשט לשאלה: "האם ניתן להרחיב את היכולות אל ה- WAN?". באופן טבעי, הדבר הראשון שבוצע הוא סריקת פורטים שגרתית, שבוצעה על ידי :nmap הכיוון שלי היה לבדוק את המימושים של כל השירותים הללו, ובאופן טבעי התחלתי עם ה- http. ממשק ה- http מאפשר ניהול נוח של הראוטר, לאחר סיפוק שם משתמש וסיסמא תחת HTTP basic.authorization מכיוון שמדובר ב- plaintext,http תוקף מתוך ה- LAN יכול היה לנסות ולהסניף את תעבורת ה- Administrator ומתוכה לחלץ את הסיסמא בקלות, אך לעת עתה נתעלם מבעיה זו ונניח שלא ניתן לבצע הסנפה שכזו. אם כן, השלב הבא במחקר הוא לחשוף את ה- filesystem. חשיפת מערכת הקבצים את גרסת ה- firmware האחרונה הורדתי מהאתר של בזק - ניתן גם היום להוריד גרסאות firmware שונות בהתאם לראוטר שיש לכם. ה- firmware הוא קובץ יחיד המכיל בתוכו את כל מה שהראוטר צריך, וביניהם מערכות קבצים. הכלי הטוב ביותר לכך הוא :binwalk הידד! נראה שמצאנו מערכת קבצים מסוג,JFFS2 שהיא מערכת קבצים די פופולרית עבור.embedded 2

3 הערה: לעיתים ניתקל במערכות קבצים לא סטנדרטיות ונצטרך לבצע מעט אבחון: טריק פופולרי של מתכנני embedded הוא לשנות ערכי magic ממערכת הקבצים על מנת שכלים כגון binwalk לא יזהו אותם. כמובן שישנם גם טריקים אחרים. השלב הבא הוא כמובן לבצע mount ולבחון את התוכן. היכן ה- cgi שלי? ישנם כמה מקומות מעניינים לבחון: 1. סקריפטי אתחול - בדרך כלל תחת etc/init.d או.etc/rc.d 2. קונפיגורציות - בדרך כלל כל קובץ שמסתיים ב- conf, במיוחד תחת.etc 3. תיקיית www עבור ה- http שלנו. אמנם ישנו סקריפט אתחול תחת,init.d אך הוא לא עושה דברים מיוחדים. לצערי, גם הקונפיגורציות לא היו משהו והכי גרוע - בתיקיית www מצאתי רק קבצי gif ו- html! היכן לוגיקת צד השרת? נדמיין ממשק - http תהליך )"httpd"( פתח socket אשר מאזין על פורט 80, והוא משרת בקשות. תהליך זה אחראי על הגשת דפי ה- html מתוך תיקיית ה- www ואחראי גם על לוגיקת ה- cgi מה שאומר שאם ה- cgi לא נמצאים בתוך מערכת הקבצים, הם כנראה "אפויים" לתוך תהליך כלשהו, והימור טוב הוא ה-.httpd נבחן אותו: אכן נראה שלפחות שמות ה- cgi "אפויים" לתוך ה- httpd. מצאתי גם קוד html ששווה לחקור את ה- httpd יותר לעומק! ושלל ירקות, מה שאומר 3

4 מחקר ה- httpd ה- httpd הוא קובץ ELF שמקומפל לארכיטקטורת MIPS )כן, זה מה שהראוטר שלכם מריץ(. למזלנו, IDA יודעת להתמודד יפה עם.MIPS הדבר הראשון שמציק בממשק ה- http בראוטר הוא שהוא דורש שם משתמש וסיסמא לכל דף )גם דפים לא קיימים!(, ולכן היינו רוצים לבחון את הלוגיקה שמטפלת ב- basic.authorization למצוא קטע קוד שמטפל בכך היה טריוויאלי xref( פשוט(, ולצערנו מתגלה פונקצייה די גדולה. החלטתי להתמקד אך ורק בפרסור שם המשתמש והסיסמא: בשלב זה בקוד, "auth_blob" מחזיק את ה- base64 שנשלח כחלק מתוך ה- headers HTTP ומייצג את שם המשתמש והסיסמא. לאחר 4 Base64 decoding )שנעשה )in-place הקוד מחפש נקודותיים, שאמורות להפריד בין שם המשתמש והסיסמא. אם אכן נמצאו נקודותיים, מחליפים אותן ב- terminator NULL )פעולה סבירה( ולאחר מכן משתמשים ב- strcpy כדי להעתיק את שם המשתמש אל באפר גלובאלי )הו, לא!(. אורך הבאפר הוא 20 בתים, וסיפוק של שם משתמש ארוך מדי מתחיל לדרוס גלובאליים אחרים. אם כן, חולשה #1: corruption memory בעת סיפוק שם המשתמש והסיסמא מתוך ה- LAN. בפועל, לא הצלחתי להגיע להרצת קוד מתוך הבאג הזה, אז לעת עתה נזכור שהוא קיים ונמשיך הלאה.

5 לאחר שמיצינו את חקירת הטיפול בשם המשתמש והסיסמא, הכיוון היה ללכת אחורה בפונקציה - לראות אילו code paths מביאים אותנו למצב של דרישת אותנטיקציה מראש. מהר מאד גיליתי את הלוגיקה שמסננת דפים מאותנטיקציה, הנה חתיכה קטנה ממה שהולך שם: הלוגיקה מסננת דפים על ידי strcmp של הדף המבוקש )כפי שהגיע ב- GET,)HTTP כאשר אם יש התאמה אז מוותרים על אותנטיקציה. חדי העין שביניכם הבחינו בוודאי ב- strstr בבלוק האחרון - והוא אכן הבאג כאן. שימו לב שבמקרה של,strstr מספיק שיהיה רשום איפשהו )למשל, בתוך משתנה )get את ה- string המבוקש על מנת לדלג על אותנטיקציה. הערה: אף על פי שזה עלול להיראות כמו,backdoor בפועל זה יותר דומה לבאג. ישנה לוגיקה דומה שמחפשת סיומות של jpg )שאותן ניתן לנצל באופן דומה( וכנראה סתם המתכנת היה גרוע. #2: מעקף אם כן כל מה שעלינו לעשות הוא לספק את המחרוזת הרצויה בתור משתנה.GET חולשה אותנטיקציה מתוך ה- LAN על כל דף שמוגש על ידי הראוטר. 5

6 הרחבת היכולות מתוך ה- LAN אז, מה נותנת לנו היכולת לעבור אותנטיקציה מתוך ה- LAN? כמובן, ניתן לעשות דברים מאד מרושעים כמו לעדכן,firmware לנתק משתמשים ולמעשה לשלוט בכל אספקט של ה- LAN, אבל אנחנו מעוניינים להגיע למצב של הרצת קוד באופן חשאי. האם אנחנו יכולים לעשות זאת? הרצת קוד נעשית בדרך כלל על ידי קריאה אל,system ולכן נחפש xref -ים אל system בתוך ה- httpd. מהר מאד נגיע אל תוצאה נראית מבטיחה: זהו אזור קוד המטפל בדיאגנוסיטקה של הראוטר, וספציפית יודע לעשות ping אל host לבחירת האדמין. באופן פשוט: ping -c 4 %s > %s מורחב על ידי sprintf ואז נשלח ישירות אל.system הקובץ שאליו תכתבנה התוצאות הוא קבוע, אבל ה- host שעליו יתבצע ה- ping נלקח מתוך פרמטר ה- GET בשם,ping_IPAddr בלי שום וידוא עליו! זה אומר שאפשר להשתמש ב- pipe או ב- backticks והם יפורשו על ידי ה- system. 6

7 הנה דוגמא משעשעת: הערה: אני יודע שאפשר לראות כאן את שם המשתמש והסיסמא שלי. היא שונתה )ובכל מקרה את ה- firmware שלי פצ'פצ'תי(, אז אל תטרחו... אם נבדוק האם נוצר קובץ בשם pwned בתוך,tmp נגלה כי אכן נוצר כזה -- הצלחנו להריץ קוד על הראוטר! מכיוון ש- httpd רץ ב- root )ולמעשה, הכל רץ ב- root בראוטר(, אנחנו יכולים לבצע הכל! חולשה #3: הזרקת פקודה מתוך ה- LAN. כמובן, שילוב של חולשה זו עם מעקף האותנטיקציה נותן למשתמש ב- LAN להריץ איזה קוד שבא לו על הראוטר באופן שקט וחשאי. אם כן, השתלטנו לגמרי על ה- LAN, והמטרה הקרובה היא לראות האם אפשר להרחיב את שליטתנו ל-.WAN אז מה קורה ב- WAN? אז, משתמש מתוך ה- LAN יכול לעשות מה שבא לו על ידי בקשת HTTP פשוטה לראוטר. המטרה היא למצוא משתמש כזה שיעשה בשבילנו את העבודה - ולגרום לו לבצע את העבודה מתוך ה- WAN. נניח שמישהו בתוך ה- LAN גולש החוצה עם http )לאתר של,DigitalWhisper לדוגמא(. זה אומר שאם תוקף יושב בין הראוטר ובין שרת ה- http )כלומר, התוקף הוא )Man In The Middle - התוקף יכול לשנות את תשובת השרת. בפרט, התוקף יכול להזריק iframe חבוי שיבצע פניית http אל השרת )עם כל הפרטים(, והקורבן שלנו )שיושב בתוך ה- LAN ( יגש אל הראוטר ויבצע עבורנו את העבודה! תקיפה זו, המוכרת בתור,CSRF כבר הוזכרה במספר גליונות קודמים, ולכן לא אכביר במילים. 7

8 שילוב החולשות למעשה, כרגע יש לנו דרך מרוחקת להריץ קוד על ראוטר בהינתן - man in the middle הזרקת iframe )על ידי הפעלת ה- ping ( ויעקוף את בקשת האותנטיקציה שיבצע את הפקודה הרצויה )על ידי כלי החולשה שמצאנו בהתחלה(. כתבתי קוד הדגמה )ב- html ( שמדגים את שילוב החולשות הללו ויוצר קובץ על הראוטר. הוא פותח גם את ה- telnetd על הראוטר )לתוך ה- LAN (, כך שיהיה קל לראות האם ההתקפה הצליחה או לא. מסקנות את רוב החולשות כאן ניתן היה למנוע בקלות. שימוש ב- strstr ו- strcpy היה אמור כבר לחלוף מן העולם, אך לצערנו עדיין קיים, במיוחד ב- embedded. צפו לראות עוד הרבה כאלה עם כל ה- hype של ה-" Things."Internet of חולשת ה- injection command אף היא די פרימיטיבית, וניתן היה להמנע ממנה על ידי סניטיזציה פשוטה של הקלט. התקפות מסוג CSRF אמורות להיות בראש של כל מתכנת צד-שרת, וגם כאן הייתה פאשלה לא קטנה קוד ה- PoC, הסברים קצת יותר מעמיקים יותר ותמונות של החתולה שלי ניתן למצוא בבלוג שלי, שיתעדכן בערך אחת לחודש, בכתובת:. 8